-
Notifications
You must be signed in to change notification settings - Fork 1.4k
SwiftBuild: Fix executable can't find dynamic lib runtime error #8650
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
@swift-ci test |
Sources/SwiftBuildSupport/PackagePIFProjectBuilder+Modules.swift
Outdated
Show resolved
Hide resolved
@swift-ci test |
@swift-ci test self hosted windows |
@swift-ci test windows |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
praise: Thank you for fixing this issue, however can we please ensure there is a test accompanying this change to ensure we don't regress?
I'm fine if you want to create a follow-up PR that adds the test, but I'd like to see a reference to the added test before merging this PR.
It's a good point! I added #8672 to track this 👍🏼 |
Update
LD_RUNPATH_SEARCH_PATHS
of executable built using the new Swift Build backend.Motivation:
For the Swift Build backend, fix a runtime issue when building & running an executable linked against a dynamic library. Given the following packages:
Package App
Package Lib
This the error that I get:
...but works just fine when using
--build-system native
.When comparing the runpath, we get this:
PS. To get the runpath, run
otool -l path/to/bin | awk '/LC_RPATH/ {getline; getline; print $2}'
.Modifications:
Update the build setting
LD_RUNPATH_SEARCH_PATHS
for executables, appending@loader_path
. This is actually an "imparted" build setting coming from dynamic libraries targets, so that's where I made the change.Result:
Now both configurations are capable of running the built
App
:For reference, this is the PIF for the sample package
App
above. Note my change affects the bottomPACKAGE-TARGET:Utils
target only. The build setting is then "imparted" on the topPACKAGE-PRODUCT:App
target.